【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit
この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『AWS における安全な Web アプリケーションの作り方(AWS-55)』の模様をレポートします。
セッション概要
情報処理推進機構(IPA) の公開している「安全なウェブサイトの作り方」をはじめとしたセキュリティを考慮した安全なウェブアプリケーションの設計ガイドラインがいくつか知られています。本セッションでは、アプリケーション開発者向けにガイドラインに則ったアプリケーションを AWS 上でどのように実装するのかを AWS プラットフォームレイヤーとアプリケーションレイヤーのそれぞれの観点から項目ごとに解説し、アプリケーション導入前、または導入後のセキュリティ対策の指標となることを目指します。
登壇者
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 保里 善太
レポート
Agenda
- Webアプリケーションの脆弱性とセキュリティガイドライン
- Web アプリケーションのセキュリティ対策
- まとめ
Webアプリケーションの脆弱性とセキュリティガイドライン
脆弱と攻撃の代表例
- SQLインジェクション
- クロスサイトスクリプティング（XSS）
- セッションハイジャック、セッション管理の不備
- アクセス制御や認可制御の⽋落
どの責任共有モデルでも「アプリケーションの保護はお客様の責任範囲」
代表的なセキュリティガイドライン
- 安全なウェブサイトの作り方
- OWASP Top 10
- OWASPが最もクリティカルと考える10種類のセキュリティリスクをまとめたもの
- その他
Web アプリケーションのセキュリティ対策
開発ライフサイクルとセキュリティ対策
1. 認証・認可とアクセス管理に注意
- AWSリソースのアクセス管理にはIAMロールを利⽤する
- 認証情報はソースコードには埋め込まない
- AWS Systems Manager Parameter Store
- AWS Secrets Manager
- (Lambdaの場合)Lambda環境変数の活用
- S3バケットのアクセス管理を確認する
- 必要以上に公開範囲の広いポリシー/ACL を設定しない
- 全開放になっているバケットをAWSTrusted Advisor や Amazon Macieで定期的にチェックする
- Amazon S3 Block Public Access を設定する
- 認証・認可は独⾃で作り込まずになるべく既存の仕組みを利⽤する
- Amazon Cognito
- AWS Single Sign-On(SSO)
- IDaaS (Onelogin、Auth0、oktaなど)を利⽤
- その他パッケージ内の機能やライブラリ
2. アプリケーション フレームワークを正しく利⽤
- SQLインジェクション対策の例
- SQL⽂の組⽴は全てプレースホルダで実装する
- SQLのPrepared Statementを利⽤する
- クロスサイトスクリプティング対策の例
- Webページに出⼒するすべての要素に対してhtmlエスケープ処理を実⾏する
- フレームワークによって⾃動的にエスケープ処理をするものと⾃分でエスケープ処理を実施する必要のあるものがある
- セッション管理の実装の例
- セッション管理は⾃作せずにアプリケーションフレームワークが備えるセッション管理機能を利⽤する
- CookieにセッションIDを保存する
- ログイン認証後にセッションIDを変更する
- 認証・認可の実装の例
- 認証・認可はフレームワークやライブラリで提供されている機能を利⽤する
- パスワードは暗号化により保護する
- パスワードのハッシュ化にはBcryptの利⽤が推奨される
- 積極的なパスワードポリシーのチェックを実施する
3. ログの取得とモニタリング
- 利⽤しているサービスに応じて少なくとも下記のログを取得して保存する
- AWS CloudTrail
- Elastic Load Balancing (ELB) アクセスログ
- Amazon CloudFront アクセスログ
- Amazon API Gateway
- VPC Flow Logs
- Amazon S3 バケット のアクセスログ
- DNS Query Logs
- アプリケーションログは以下の構成を例にCloudwatch LogsやS3に保存
4. コードレビューの実施
公式に発表されている各⾔語におけるコーディング規約の⼀例
- Python ⇨ Pythonの公式コーディング規約 PEP8
- Java ⇨ JPCERTによるJava コーディングスタンダード
- Ruby ⇨ Ruby AssociationによるRubyコーディング規約
5. セキュリティテストを実施
- 静的アプリケーションセキュリティテスト (SAST)
- アプリケーションのソースコードが対象
- 開発者の実装にセキュリティ上の問題点がないかを確認
- Amazon CodeGuru ReviewerSecurity Detector（関連の公式ブログ）
- GitHub Code Scanningによるセキュリティスキャン
- 動的アプリケーションセキュリティテスト (DAST)
- OWASP ZAP (Zed Attack Proxy)
- 完全無償で利用可能、簡易スキャン、静的スキャン、動的スキャンの３段階のスキャン⽅法がある
- 侵⼊テストについて
- 特定のサービスの侵⼊テストは AWS の事前承認なく実施可能
6. 必要に応じてWAFによる追加的な保護を実施
- 悪意のあるリクエストのブロック（CloudFront、ALB、API Gatewayが対象）
- SQLインジェクション
- クロスサイトスクリプト
- IPブラックリスト
- カスタムルールに基づいたWebトラフィックのフィルタ
- IP Match、正規表現など様々な条件が可能
- AWS managed rules for AWS WAF (AMR)も利用可
- モニタリングとチューニング
- Amazon CloudWatchメトリクス、アラーム
- ロギング
AWS WAFで保護できること
7.継続的なセキュリティテスト/脆弱性診断を実施
有効な⼿法の⼀つとして、DevOpsのパイプラインにセキュリティテストを組み込む
まとめ
- サービスにより責任の範囲は変化するが、常にアプリケーションのセキュリティ対策はお客様の責任範囲
- Webアプリケーションのセキュリティガイドラインを読み返して脆弱性と対策を理解しましょう
- アプリケーションの開発ライフサイクルにおいて必要となるセキュリティ対策が異なることを理解しましょう
- 各開発フェーズにおけるセキュリティ対策のポイントを確認しましょう
- 認証・認可とアクセス管理に注意
- アプリケーションフレームワークを正しく利⽤
- ログの取得とモニタリング
- コードレビューの実施
- セキュリティテストを実施
- 必要に応じてWAFによる追加的な保護を実施
- 継続的なセキュリティテスト/脆弱性診断を実施
所感
アプリケーションレイヤのセキュリティで考慮すべき項目がわかりやすく整理され、必要なアクションが何なのかよく理解できるセッションでした。
クラウド上で構築したリソースを安定して運用するには、セキュリティ設定はクライアント自身で設定しなければならないので、プロジェクト内でしっかり要件を洗い出しましょう。（とくに1.認証認可とアクセス管理は必須級）
